home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20000217-20000824
/
000222_news@columbia.edu _Mon Apr 24 13:06:36 2000.msg
< prev
next >
Wrap
Internet Message Format
|
2000-08-23
|
7KB
Return-Path: <news@columbia.edu>
Received: from watsun.cc.columbia.edu (watsun.cc.columbia.edu [128.59.39.2])
by uhaligani.cc.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA06779
for <kermit.misc@cpunix.cc.columbia.edu>; Mon, 24 Apr 2000 13:06:36 -0400 (EDT)
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA00941
for <kermit.misc@watsun.cc.columbia.edu>; Mon, 24 Apr 2000 13:06:35 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.9.3/8.9.3) id MAA19975
for kermit.misc@watsun.cc.columbia.edu; Mon, 24 Apr 2000 12:51:07 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: Ishikawa <ishikawa@yk.rim.or.jp>
Subject: Re: Parity incorrectly reported, and RTS/CTS problem on Solaris 7 for
Date: Tue, 25 Apr 2000 01:41:29 +0900
Organization: RIMNET InterNetNews site
Message-ID: <39047938.734774D0@yk.rim.or.jp>
To: kermit.misc@columbia.edu
Frank da Cruz wrote:
> In article <3904650F.A10717AF@yk.rim.or.jp>,
> Ishikawa <ishikawa@yk.rim.or.jp> wrote (of C-Kermit 7.0):
> : First, thank you for the great package. I asked a few questions
> : concerning the usage of 8 bits byte, and an even parity several weeks ago
> : on linux and after the kind answers I could get kermit going on Debian
> : GNU/linux well.
> :
> Good...
>
Again thank you!
>
> : [1] One cosmetic bug.
> .
...
>
> This is not actually a bug. As far as Kermit protocol is concerned, the
> parity really is "none". This means it is using all 8 bits of each byte for
> data, and it doesn't have to use single shifts or locking shifts to encode
> bytes whose 8th data bit is 1. But yes, I agree it might be clearer to list
> something like "none (8E1)" here. I'll add it to my list.
>
Again, your clarification is appreciated.
>
> : Now a little complicated one.
> : I am not sure if this is a bug or feature.
> :
> : [2] A user expectancy problem. RTS/CTS is not supported by
> : pre-compiled binary for Solaris 7 for x86.
> :
> : But kermit doesn't complain if I specify rts/cts flow-control, and
> : SILENTLY ignored my request, so to speak.
> :
> Thanks for the report. We don't have hands-on access to Solaris x86 (any
> version) here, so never noticed this one. All our Solaris x86 binaries were
> built at remote sites, where we couldn't experiment with modems, or sent in
> by others. (Note: we still don't have a Solaris 2.6 x86 binary.)
Well, maybe I can make the solaris 7 for x86 binary later on if you need one
once we figure out what the correct settings of macros should be.
>
> C-Kermit 7.0 for Solaris is built with -DCK_RTSCTS, which tells it to
> include the commands for setting, showing, and using RTS/CTS. This has been
> true ever since Solaris 2.0. It happens automatically in ckcdeb.h, because
> STERMIOX is defined, which in turn means that <system/termiox.h> is available,
> which defines the System-V based hardware flow-control API.
Sorry, I didn't dig enough and notice this sysV API. I was just
reading through the code to find POSIX RTSCTS handling code which
I think works on linux.
>
> : It simply failed to set RTS/CTS and merrily goes on processing. Beat me why
> : it did NOT give me any warning about not-supported RTS/CTS or maybe the code
> : forgot to handle the non-supported case since the code to handle CRTSCTS is
> : cluttered with many #ifdef's.)
> :
> That's what makes it work on hundreds of different platforms :-)
>
Yeah, right :-)
I need to insert a few fprintf lines in order to find out if the code I wanted to
execute was really get executed.
>
> The reason you didn't get a warning is that C-Kermit is indeed calling the
> <system/termiox.h> APIs for setting RTS/CTS, and the APIs are not returning
> an error. (Take a debug log and search for "tthflow".)
>
Hmm... I will look into it. Here is a dumb question. What is the proper way to
obtain debug log? I found the usage of macros, which seemed to be the
debug macros in the source code, but didn't find out how to enable it
from the command line.
>
> : Anyway, after I modified the supplied `makefile' to define
> : POSIX_CRTSCTS (and inserted a few fprintf(stderr,"...") lines just to
> : let me make sure the expected lines to enable RTS/CTS flow control are
> : executed) and recompiled the C-kermit-7 code, I verified that now that
> : the RTS/CTS enable code is executed and the transfer at 115200 bps
> : (8E1) with flow-control of rts/cts works and transfer of wermit binary
> : (about 1.6MB) using packet length of 3999 (default) with D-type packet
> : went well(!).
> :
> Good! So it seems that the System-V RTS/CTS APIs have stopped working in
> Solaris 8 and a non-backwards-compatible switch as been made to the POSIX
***** this should read solaris7 (since mine is solaris 7), but probably solaris 8
behaves the same.
>
> APIs. This is a "double ended error": the old API is broken, but it doesn't
> inform the application of any problem.
It looks to be the case.
>
>
> : I have no idea at this moment if solaris 7 for sparc (not x86) should work
> : with this modification, but it should. If not, maybe we need a different
> : target (solars7x86 against solaris7) just in case. YMMV.
> :
> This, of course, is an important question. What is the earliest version of
> Solaris that has the POSIX API for RTS/CTS available (and working!)? What
> is the latest version of Solaris that has the System V API working? Is there
> a difference between x86 and Sparc versions?
>
I can check 2.5.1 for sparc, 2.4 for x86 if necessary (and solaris 7 for x86 as I
explained above.)
>
> : Here is the patch to makefile (for solaris 7 for x86).
> : I simply inserted -DPOSIX_CRTSCTS.
> : (Is this macro supposed to be automatically defined when one says
> : -DPOSIX? From the comment I found in the code, I don't think so, but
> : just have to ask.)
> :
> No, it is not, and should not be. You can never assume anything like this.
> To C-Kermit, -DPOSIX means POSIX 1.0, which has nothing whatsoever to say
> about hardware flow control; POSIX OS's implement hardware flow control in
> all sorts of creative and incompatible ways.
>
> I'm cross-posting this reply to the Solaris lists in case anybody there can
> answer the questions above. Unfortunately, however, the only real test is
> to build C-Kermit both with and without -DPOSIX_CRTSCTS on every Solaris
> platform and test the flow control.
>
> - Frank
Hmm ... tough cases to solve. Come to think of it, the sparc box I have access
has
already used up both ports and I am not sure if I can remove the serial line for
a while
to test kermit (and I need somewhat longer cross-cables!). We need many
volunteers.
Anyway, again million thanks!
I wonder MS has this kind of quick feedback from none other than the
one of the original authors of the software :-)
Happy Hacking,
Ishikawa